home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 651 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.7 KB  |  66 lines
  1. Newsgroups: comp.std.c
  2. Path: news.uunet.ca!wildcan!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: EXIT_SUCCES != EXIT_FAILURE?
  5. Message-ID: <1996Mar26.141531.9203@sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <tompa.827763954@news> <4j7p4p$4n8@castle.nando.net>
  8. Date: Tue, 26 Mar 1996 14:15:31 GMT
  9.  
  10. Thomas Padron-McCarthy (tompa@ida.liu.se) writes:
  11.  
  12. > > I wonder: Does the standard guarantee that EXIT_SUCCESS and
  13. > > EXIT_FAILURE are different?
  14.  
  15. Bill McCarthy (actuary@nando.net) writes:
  16.  
  17. > Not only are they not guaranteed to be different.  EXIT_SUCCESS is
  18. > not guaranteed to be zero, and EXIT_FAILURE is not guaranteed to
  19. > be different from 0.  They are implementation defined and should
  20. > only be used as an argument to exit() or in a return from main().
  21. > 
  22. > They are defined 7.10.4.3 of the standard.
  23.  
  24. Section 7.10 specifies that
  25.  
  26. #  ...
  27. #  EXIT_FAILURE
  28. #    and
  29. #  EXIT_SUCCESS
  30. # 
  31. #  ... expand to integral expressions that may be used as argument to
  32. #  the exit function to return successful or unsuccessful termination
  33. #  status, respectively, to the host environment.
  34.  
  35. The passage in 7.10.4.3 essentially reiterates this with additions:
  36.  
  37. #  If the value of status is zero or EXIT_SUCCESS, an implementation-
  38. #  "successful termination" is returned.  If the value of status is
  39. #  EXIT_FAILURE, an implementation-defined form of the status
  40. #  "unsuccessful termination" is returned. ...
  41.  
  42. As "successful termination" and "unsuccessful termination" are in italics
  43. here (rendered as quotes in this ASCII text), they are being defined by
  44. this passage, so they just mean the effects that zero or EXIT_SUCCESS
  45. on the one hand, and EXIT_FAILURE on the other, respectively have.
  46.  
  47. It seems clear to me that the intent of both passages is to define them
  48. as being distinct statuses, which implies that EXIT_SUCCESS and EXIT_FAILURE
  49. must yield distinct values.  But this is not explicitly stated, and obviously
  50. Bill disagrees.
  51.  
  52. I might note that it is also not explicit that they should yield *constant*
  53. values.  One can imagine an implementation where EXIT_FAILURE yields one
  54. value if some particular feature was ever used in the program, and another
  55. value if it was not, as a debugging aid.  In that case, if a user function
  56. returns EXIT_FAILURE, comparing the returned value for equality with
  57. EXIT_FAILURE later might not work.  This strikes me as a rather strained
  58. interpretation, though, and I would not object if a ruling prohibited it.
  59. See below. :-)
  60. -- 
  61. Mark Brader           \ "Nitwit ideas are for emergencies.  The rest of the
  62. msb@sq.com             \ time you go by the Book, which is mostly a collection
  63. SoftQuad Inc., Toronto  \ of nitwit ideas that worked.   -- Niven & Pournelle
  64.  
  65. My text in this article is in the public domain.
  66.